Root cause

codspeed-memtrack holds file capabilities (cap_bpf, cap_perfmon, cap_sys_admin). A non-root user executing a capability binary enters glibc secure-execution mode (AT_SECURE=1), which strips LD_* variables from the environment before main().

The memory executor sourced the forwarded environment around memtrack:

bash -c "source ENV && memtrack track … '<bench>'"   ← LD_LIBRARY_PATH restored here
└─ codspeed-memtrack                                 ← cap binary: glibc strips LD_* again
   └─ bash -c <bench>                                ← inherits stripped env ❌

So LD_LIBRARY_PATH was restored and then stripped a second time, before the benchmark memtrack spawns could inherit it.

Walltime is unaffected because it layers privilege escalation (sudo/perf/systemd scope) outside the env re-source, keeping source at the innermost layer.

Fix

Source the env inside the command memtrack runs via its own bash -c, below the capability boundary:

codspeed-memtrack track … "source ENV && <bench>"
└─ codspeed-memtrack           ← strips LD_* (no longer matters)
   └─ bash -c "source ENV && <bench>"   ← re-sources below the cap binary
      └─ <bench>                        ← sees LD_LIBRARY_PATH ✅

• Add prefix_command_with_env for the raw source <file> && <cmd> snippet (no outer bash -c) and reuse it from wrap_with_env.
• MemoryExecutor::build_memtrack_command now prefixes the bench command and passes it as memtrack's argument; the outer bash wrapper is gone.

Test

test_memory_executor_forwards_ld_library_path (Linux + GITHUB_ACTIONS gated) exercises this end-to-end. The existing ..._forwards_path test never caught it because PATH is not an LD_* variable.

Verification

Reproduced the mechanism with a minimal capability binary that runs its argument via bash -c (memtrack's exact structure), as a non-root user: